Cloudflare has introduced a significant enhancement to its Durable Objects (DO) by integrating zero-latency SQLite storage, fundamentally changing how applications can manage data in the cloud. Traditional cloud storage often suffers from latency due to network access and the need for synchronization across multiple clients. However, with Durable Objects, application code runs directly where the data is stored, eliminating the need for context switching and allowing for near-instantaneous access to data. Previously, Durable Objects provided only key/value storage, but the new integration with SQLite allows for a full SQL query interface, complete with tables and indexes. SQLite is widely recognized for its speed and reliability, making it an ideal choice for this new architecture. By embedding SQLite directly within the Durable Objects, Cloudflare enables applications to execute SQL queries with minimal latency, often completing in microseconds. Durable Objects are part of the Cloudflare Workers serverless platform, functioning as small servers that maintain state both in-memory and on-disk. Each DO can be uniquely addressed, allowing for global access and coordination of operations. This architecture is particularly beneficial for applications requiring real-time collaboration, such as document editing, where multiple users can interact with the same data seamlessly. The design of Durable Objects emphasizes scalability by encouraging the creation of multiple objects to handle increased traffic rather than relying on a single object. This approach allows for efficient management of state and traffic distribution across the network. One of the standout features of the new SQLite integration is the synchronous nature of database queries. Unlike traditional asynchronous database calls, which can introduce complexity and potential bugs, the synchronous queries in Durable Objects ensure that the application state remains consistent and predictable. This design choice simplifies coding and enhances performance, as the application can execute queries without waiting for I/O operations to complete. To address concerns about write durability, Cloudflare has implemented a mechanism called "Output Gates." This system allows applications to continue processing without waiting for write confirmations, while still ensuring that responses to clients are only sent after confirming that writes have been successfully stored. This dual approach maintains high throughput and low latency. The integration also simplifies common database issues, such as the "N+1 selects" problem, by allowing developers to write straightforward queries without needing to optimize for performance intricacies. Additionally, SQLite-backed Durable Objects offer point-in-time recovery, enabling users to revert to any state within the last 30 days, providing a safety net against data corruption. Developers can easily implement SQLite-backed Durable Objects by defining their classes and migrations in the Cloudflare environment. The pricing model for this new feature aligns with existing Cloudflare services, offering a competitive structure for SQL queries and storage. In contrast to Cloudflare's D1 product, which is a more managed database solution, SQLite-in-Durable Objects provides a lower-level building block for developers who want more control over their applications. D1 operates within a traditional cloud architecture, while SQLite-in-DO allows for colocated application logic and data storage, offering unique advantages for specific use cases. The underlying technology for this new feature is the Storage Relay Service (SRS), which efficiently manages data persistence by combining local disk speed with the durability of object storage. SRS records changes in a log format and utilizes a network of follower machines to ensure data integrity and availability. Overall, the introduction of zero-latency SQLite storage in Durable Objects represents a significant advancement in cloud computing, enabling developers to build faster, more reliable applications with enhanced data management capabilities.

SlateDB is an innovative embedded storage engine that leverages object storage technology, distinguishing itself from traditional LSM-tree storage engines. By utilizing object storage, SlateDB offers virtually limitless storage capacity, exceptional durability, and straightforward replication processes. One of the standout features of SlateDB is its reliance on the durability of the underlying object store, which boasts an impressive durability rate of 99.999999999%. This high level of reliability ensures that data remains safe and intact over time. SlateDB operates on a zero-disk architecture, eliminating the risks associated with physical disks, such as failures and corruption. This design choice enhances the overall stability and performance of the database. Replication is simplified in SlateDB, as it allows the object store to manage replication instead of requiring complex protocols. This approach streamlines the process and reduces the potential for errors. The performance of SlateDB can be tuned to meet specific needs, whether the priority is low latency, cost-effectiveness, or high durability. This flexibility makes it suitable for a variety of applications and use cases. SlateDB supports a single writer and multiple readers, with built-in mechanisms to detect and manage "zombie" writers, ensuring data integrity and consistency. Developed in Rust, SlateDB is designed to be an embeddable library, making it accessible for use with various programming languages. Getting started with SlateDB is straightforward; developers can easily add it to their project dependencies and begin utilizing its features right away. Overall, SlateDB represents a modern solution for embedded database needs, combining the advantages of object storage with a user-friendly design and robust performance capabilities.

Distributed SQLite databases sacrifice consistency, transactions, and scalability. Traditional databases like PostgreSQL, paired with effective HTTP caching for speed, are better choices than using distributed SQLite. The upside to SQLite databases is that they are really fast, but at some point, the maintenance overhead outweighs the speed benefits.

Notion recently improved its browser performance by using SQLite for client-side caching. This led to a 20% increase in page navigation speeds through a SharedWorker architecture to manage concurrency and prevent database corruption. SQLite was implemented using WebAssembly for local data storage and offline functionality. In this post, the team at Notion goes through challenges they faced with slow disk reads and initial page load times.

SQLite's serverless nature lets developers embed it directly within applications, with a user-friendly console to provide straightforward access. It also has data import and export, native JSON handling, and advanced SQL capabilities like Common Table Expressions and set operations.

SSDs have a fast read and write throughput, but also suffer from high latency during write operations. To mitigate this issue, database systems use techniques like group commits and asynchronous processing. Enterprise-grade SSDs with capacitor-backed write caches can alleviate the latency problem, but at a higher cost.

Uber developed CacheFront, a highly efficient caching layer integrated with its Docstore database, to achieve significant latency reductions (75% in P75, 67% in P99.9) and enable over 40M reads per second.

A developer found that a webpage that was used for performance tracking was really slow. They discovered that inefficient SQL queries were causing long delays. By understanding the SQLite query planner, the developer added indexes and a materialized view to improve the database query performance and thereby speed up the page load time.

RevenueCat's caching system handles 1.2 billion daily API requests by distributing the load among servers and using the cache for hot data. For low latency, it uses pre-established connections and fails fast on unresponsive servers. To keep the cache up and warm, it plans for server failures and uses fallback pools. To maintain consistency, it employs write failure tracking and consistent CRUD operations.

Cloudflare's "pingora-origin" service processes a massive amount of HTTP requests - a small function called "clear_internal_headers" was identified as consuming a significant portion of its CPU time. To optimize this function, Cloudflare explored different data structures, eventually settling on a trie-based approach, which resulted in a new open-source Rust crate called "trie-hard". The trie-hard implementation reduced the CPU utilization of the function, achieving a 1.28% decrease in compute time, which matters a lot at scale.

Notion sped up its web browser application by implementing SQLite caching using WebAssembly. It faced challenges with cross-origin isolation and data corruption due to concurrency issues when multiple tabs accessed the database simultaneously. Notion resolved these issues by developing a SharedWorker architecture where only one tab actively interacts with the SQLite database while others can still make queries. It also addressed regressions like slower load times and performance issues on slow devices by loading the WASM SQLite library asynchronously and implementing a “race” mechanism between SQLite and API requests.

Dolt, a version controlled database, uses cryptographic checksums to address data blocks. While this might lead to potential collisions where different data blocks have the same checksum, the chance of collision is extremely low due to the combo of SHA-512, a strong hash function, and a 20-byte key, which provides a collision resistance of 2^80. This means that even with billions of objects stored, the probability of a collision is small and negligible.

Cloudflare has introduced a new feature called Speed Brain, designed to significantly enhance web page loading times by up to 45%. This innovation is particularly relevant in an era where performance is crucial for user engagement and retention. Speed Brain leverages the Speculation Rules API to anticipate user navigation patterns, allowing it to prefetch content before users actually click on links. This proactive approach means that when a user decides to navigate to a new page, the content is already cached in their browser, resulting in near-instant loading times. The initial implementation of Speed Brain focuses on prefetching static content when a user initiates a touch or click event. Future updates will introduce more aggressive models, including prerendering, which will not only fetch but also render the next page in advance. This capability aims to eliminate latency for static websites without requiring any configuration from users. To illustrate its effectiveness, consider an e-commerce site where users typically navigate from a parent category to specific items. By analyzing global request logs, Speed Brain can predict that a user viewing "Men's Clothes" is likely to click on "Shirts." Consequently, it begins delivering the relevant static content, such as images, even before the user clicks the link, resulting in an instantaneous page load when the click occurs. Early tests have shown that this method can reduce the Largest Contentful Paint (LCP) metric by up to 75%, which measures how quickly the largest visible element on a page loads. Speed Brain is available to all Cloudflare plan types at no additional cost. Users can enable it easily through their dashboard or API. For free domains, Speed Brain is activated by default, while Pro, Business, and Enterprise users need to enable it manually. Additionally, enabling Real User Measurements (RUM) is recommended to track performance improvements and optimize prefetching rules based on actual user behavior. Understanding how browsers load content is essential to appreciate the significance of Speed Brain. When a user navigates to a web page, the browser must establish a secure connection, send an HTTP request, and retrieve the necessary resources, including HTML, CSS, and JavaScript. This process can introduce delays, especially as users navigate through multiple pages. Speed Brain aims to mitigate these delays by prefetching and prerendering content based on user interactions, thus providing a smoother browsing experience. Historically, prefetching techniques have existed but often lacked the necessary data insights and flexibility. Previous methods required developers to manually specify which resources to prefetch, leading to inefficiencies. Cloudflare's Speed Brain addresses these limitations by dynamically determining prefetch candidates based on real-time user interactions, rather than relying on static configurations. The implementation of Speed Brain is made possible through the Speculation Rules API, which allows the browser to receive guidance on when to prefetch content. This approach minimizes the risk of stale configurations and incorrect prefetching, ensuring that resources are only fetched when they are likely to be needed. The initial conservative model prioritizes safety and efficiency, with plans to explore more aggressive settings in the future. Cloudflare's extensive global network enhances the effectiveness of Speed Brain by serving prefetched content directly from its CDN cache, significantly reducing latency. The feature is currently supported in Chromium-based browsers, with plans for broader adoption as the web community standardizes the Speculation Rules API. As Speed Brain continues to evolve, Cloudflare is exploring the integration of machine learning to refine its predictive capabilities further. This will enable more accurate prefetching based on user behavior, enhancing performance while maintaining user privacy. Future developments may also include prerendering capabilities and the potential bundling of Speed Brain with other performance-enhancing features like Argo Smart Routing. In conclusion, Speed Brain represents a significant advancement in web performance optimization, providing users with faster loading times and a more seamless browsing experience. Cloudflare encourages users to enable this feature and utilize RUM tools to monitor its impact on their website's performance.

Delta Lake is emerging as a leading open protocol for serverless ACID databases, particularly suited for analytics workloads. Its simplicity and scalability have made it a popular choice, akin to DuckDB in the realm of serverless transactional databases. While Iceberg is a similar contender, Delta Lake's straightforward approach is the focus of this discussion. The implementation of a Delta Lake-inspired serverless ACID database can be achieved with just 500 lines of Go code, requiring no external dependencies. This implementation will allow for the creation of tables, insertion of rows, and scanning of all rows while supporting concurrent readers and writers, all while maintaining snapshot isolation. However, certain features of Delta Lake, such as updating and deleting rows, checkpointing transaction metadata, and compaction, will not be covered in this initial exploration. Delta Lake operates by writing immutable data files to blob storage and managing transaction metadata through a naming scheme that incorporates transaction IDs. This method allows for concurrency control via an atomic PutIfAbsent operation on the metadata file. When a transaction is initiated, it identifies the highest existing transaction ID and increments it for its own use. If a transaction attempts to commit with a duplicate ID, the write operation fails, ensuring that concurrent transactions do not interfere with each other. The implementation begins with setting up basic assertion methods, a debug method, and a UUID generator in Go. The core requirement for the blob storage is to support atomic writes, listing locations by prefix, and reading bytes from specific locations. The design diverges from Delta Lake by using a single directory for all files, simplifying the implementation of listing files by prefix. The atomic PutIfAbsent functionality can be implemented using various cloud storage providers, but for simplicity, a filesystem-based approach is adopted. This leverages POSIX file creation semantics to ensure atomicity. The file storage implementation includes methods for writing, listing, and reading files, with careful error handling to maintain data integrity. The ACID properties of Delta Lake are maintained through the immutability of data files, allowing for consistent snapshots even when concurrent transactions are in progress. The implementation sketches out the structure of transactions, which consist of a list of actions, including defining table schemas and adding data files. A client structure is established to manage transactions, with methods for starting transactions, creating tables, writing rows, and committing transactions. The transaction management ensures that all operations are performed within the context of a transaction, maintaining the integrity of the database. When writing data, rows are buffered in memory until a threshold is reached, at which point they are flushed to disk as immutable data objects. The scanning functionality is designed to return an iterator, allowing for efficient traversal of both in-memory and on-disk data. Committing a transaction involves flushing any remaining data and attempting to write the transaction's metadata atomically. If another concurrent transaction has modified the state, the commit will fail, ensuring that only one transaction can succeed at a time. Testing the implementation reveals that concurrent writers will fail if they attempt to commit overlapping transactions, while readers can still access a consistent snapshot of the data. This behavior aligns with the principles of snapshot isolation, allowing for safe concurrent operations. The exploration concludes with an invitation to further investigate the Delta Lake paper and its specifications, encouraging readers to consider enhancements such as handling updates and deletes, transaction log checkpoints, and data object compaction. The simplicity and effectiveness of the approach highlight the potential for building robust serverless ACID databases using straightforward techniques.

SoundCloud kept its initial technology stack simple. As the platform grew, it made strategic choices, like adding HAProxy and RabbitMQ, to address performance bottlenecks caused by long-running requests and high traffic. To further optimize performance and support its growth, SoundCloud eventually decoupled its architecture, introduced caching and new data stores, and transitioned towards a microservices model.

Local-first software stores and processes data locally on users' devices while using the internet for backup when connected. Resilient Sync uses a simple log format to track changes and assets, allowing offline data processing and easy sync across devices. It offers independence from push notifications, the ability to load entries without knowing their content, easy detection of missing data, and the option for data replication and peer-to-peer synchronization.

A vector database built on top of the powerful SQLite technology. It can handle millions of queries and has a nice API for vectors.

SQLite is a great database to use with Ruby on Rails apps for MVPs. It simplifies deployment and configuration since it is just a single executable and database file. SQLite is fast and scales quite well for smaller applications. Configuration for the database and engine lives within the Rails application itself, allowing for granular control and experiences like branch-specific databases.

Notion implemented WebAssembly (WASM) SQLite in its web app. This resulted in a 20% reduction in page navigation latency. To achieve this, its team used Web Workers to offload database operations to background threads and a SharedWorker with the Web Locks API to fix data integrity issues. They also addressed issues of slow disk reads by implementing a "race" between disk cache and network requests.

Facebook used Memcached, a key-value store, to efficiently handle billions of requests per second. It achieved this by scaling Memcached at three levels: cluster, region, and worldwide. It used parallel requests and batching, optimized client-server communication, and managed congestion effectively to reduce latency. “Memcache pools” were used to reduce load on their databases.

JunoDB is a highly reliable database developed by PayPal with an architecture that supports near-constant availability and efficient handling of massive data request loads. Its architecture includes a client library, a proxy with load balancing, and storage servers using RocksDB.

Wafris, an open-source web application firewall company, has transitioned from using Redis to SQLite as the backing datastore for its Rails middleware client. This change, detailed by Michael Buckbee in a blog post, stems from the challenges users faced with Redis deployment, which often complicated the user experience and introduced issues that detracted from Wafris's goal of simplifying web application security. Initially, the decision to use Redis was influenced by its accessibility within the Heroku ecosystem and the success of similar projects. However, as Wafris grew, it became clear that requiring users to manage a Redis database was counterproductive. Many users encountered difficulties that made the setup cumbersome, leading to a reconsideration of the architecture. The performance of Redis, while generally fast, was hindered by network latency, especially in cloud environments where every HTTP request needed to be evaluated against security rules. This latency became a significant bottleneck, prompting the need for a more efficient solution. The architectural shift to SQLite aimed to eliminate network round trips, thereby improving performance. SQLite was chosen for its ability to handle read operations efficiently, which is crucial for Wafris's functionality. The benchmarking process revealed that SQLite outperformed Redis in their specific use case, achieving approximately three times the speed in local tests. This performance gain was particularly valuable as it negated the need for network latency, which would have further slowed down operations. The new architecture also addressed the complexities of deployment. With SQLite, users no longer needed to manage a separate database server. Instead, the Wafris client would periodically check for updates and download a new SQLite database as needed, simplifying the installation process and increasing successful deployments. While the write operations were initially overlooked in the testing, the architecture was adapted to handle them asynchronously. This approach allowed for batch reporting without burdening the client with database write responsibilities, focusing instead on delivering a fast and easy-to-use solution for users. Overall, the transition to SQLite has resulted in a more streamlined and efficient Wafris client, enhancing user experience and improving the security of web applications. The company continues to prioritize ease of deployment and performance, aiming to provide a robust solution for web application security.